We should address this todo as a part of this as well. The verification for a policy and an attestation should be the same I think.

yeah for sure. The only difference with policy is that there isn't going to be a policy document for verifying the policy... if that makes sense. So we ought to keep the number of ways that one can use to verify the policy signature small...

Do you think it makes sense to make all these changes in this PR?

only difference with policy is that there isn't going to be a policy document for verifying the policy

I think it would be the same as the step verification: https://github.com/in-toto/go-witness/blob/main/policy/policy.go#L230

We're essentially defining the functionary from the CLI

yeah the problem though is that defining all the available parameters for the functionaries from the CLI could quickly become unwieldly imo. Consider this functionary:

        {
          "type": "root",
          "certConstraint": {
            "commonname": "*",
            "dnsnames": [
              "*"
            ],
            "emails": [
              "[email protected]"
            ],
            "organizations": [
              "*"
            ],
            "uris": [
              "*"
            ],
            "roots": [
              "wippywoo"
            ]
          }
        }

In this case, we would need to define:

1. cert-constraints (commonName, DNSName, emails, organizations, uris)
2. roots (this includes root CA cert, intermediates (which doesn't quite seem clear in the tools current form), and we might need to supply timestamp servers alongside that.

How we would present that in a flag form I am not quite sure on. To me I think that limiting support for the number of policy signing mechanisms might be the way forward? It also seems to be the case to me that TUF may be a solution to this. @kairoaraujo any thoughts?

I agree that it is unwieldy, however I would normally expect the user to wrap this in a bash script, or maybe a "witness verify" github action. I also think we could provide some syntactic sugar for sigstore that would let us provide better UX for the common use case while being secure by default.

ex:

for enterprise use:
witness verify -p signedpolicy.json -k ca.pem -i int.pem --commonname="*" --dnsname="*" --email="[email protected]" --organization="*" --uri="*" --root="wippywoo" artifact.tar

for sigstore:
witness verify -p signedpolicy.json --use-sigstore --use-archivista --email="[email protected]" artifact.tar

We would also need to provide a TSA pem or add support for Rekor